본문으로 건너뛰기

SHIELD DRM 사용 관련 FAQ

본 문서는 SHIELD DRM 관련 접수된 Q&A와 기술적 배경/대응 가이드를 함께 기재된 문서입니다.

문서 변환 / 소유권​

Q1. 클라우드 업로드 시 AIP 문서 소유자를 사용자 본인으로 설정할 수 있나요?​

현상: 로컬 PC의 DS 문서를 클라우드에 업로드하면, AIP 문서 소유자가 사용자 본인이 아닌 Security365 앱으로 표시됩니다.

불가합니다.
클라우드에서 변환 시 Azure Application 권한으로 변환이 이루어지며, 사용자 위임 권한을 통한 변환은 지원되지 않습니다.

기술 배경​

SHIELD DRM은 Microsoft Entra ID(구 Azure AD) 기반의 MSAL 인증 흐름을 지원하며, 디먼(Daemon) 유형을 채택합니다.

  • 디먼(Daemon) 방식이란?
    • 백그라운드에서 동작하는 서비스/애플리케이션이 사용자 개입 없이 인증/인가를 수행하는 방식입니다.
    • 서버 간 통신 또는 자동화 작업에서 주로 사용합니다.
  • 클라이언트 자격 증명(Client Credential) 플로우
    • 앱 자체의 Client ID / Client Secret을 이용하여 토큰을 획득합니다.
    • 사용자 로그인 정보가 필요하지 않습니다.
    • 결과적으로 사용자 본인 소유자로 문서를 변환하거나 소유권을 위임하는 것이 불가합니다.

대응 방안​

  • 레이블 정책에서 소유자와 무관하게 레이블을 변경할 수 있도록 설정 가능합니다.
    • 이 정책을 활성화하면 앱 소유 문서도 정상적으로 레이블 변경 가능합니다.

참고 문서​

MSAL 인증 흐름 다이어그램

이벤트 리시버​

Q2. 신규 SharePoint Site 생성 시 이벤트 리시버 자동 설치를 막을 수 있나요?​

네, 가능합니다.
해당 동작은 SHIELD DRM의 "실시간 감지" 기능으로 제어합니다.

  • 실시간 감지 ON : 신규 OneDrive/SharePoint 사이트가 생성되면 이벤트 리시버를 자동 설치합니다.
  • 실시간 감지 OFF : 신규 사이트가 생성되어도 이벤트 리시버가 자동 설치되지 않으며, 관리자가 직접 설치해야 합니다.

따라서 신규 사이트에 대한 자동 설치를 원치 않으시면 "실시간 감지"를 OFF로 설정하시면 됩니다.

설정 위치​

  • SHIELD DRM 관리자 페이지 → [연동 관리] → 이벤트 리시버 메뉴 내 정책(옵션) 영역에서 설정합니다.
  • ※ 정확한 메뉴 명칭/경로는 운영 중인 관리자 화면 버전에 따라 다를 수 있어, 실제 화면 기준으로 최종 확인이 필요합니다.

Q3. 특정 사이트만 이벤트 리시버를 삭제하고 자동 재설치되지 않도록 할 수 있나요?​

문의하신 형태 — 즉 "특정 사이트만 이벤트 리시버를 삭제한 뒤, 해당 사이트를 자동 재설치 대상에서 (영구적으로) 제외"하는 기능은 현재 제공되지 않습니다.

  • 이벤트 리시버의 삭제 자체는 관리자 페이지에서 수행할 수 있으나,
  • "특정 사이트를 재설치 대상에서 제외" 상태로 고정하는 사이트별 예외 설정은 없습니다.
  • Q2의 "실시간 감지"는 신규 생성 사이트 전체에 대한 ON/OFF 설정이며, 특정 사이트만 선택적으로 제외하는 용도가 아닙니다.

따라서 "특정 일부 사이트 대상 삭제 + 자동 재설치 제외" 요구사항은 현재 기능으로는 충족되지 않습니다.

Azure 앱 구성​

Q4. SHIELD DRM Azure 앱이 6개인 이유와 각 앱의 역할은 무엇인가요?​

6개 앱은 앱별로 서로 다른 역할을 수행하지 않습니다.
SHIELDRM_Main과 Sub1~5는 기능적으로 동일한 앱이며, 앱을 6개로 나누어 둔 이유는 Microsoft Graph API의 쓰로틀링(호출량 제한)을 분산하기 위함입니다.

앱 구성​

  • Security365 (별도 1개 앱) : Softcamp 서비스들을 사용할 수 있는 권한을 가진 공통 앱입니다.
  • SHIELDRM 앱 (6개 = Main + Sub1~Sub5) : SHIELD DRM 서비스를 사용하기 위한 권한을 가진 앱입니다. (관리자 화면에 표시되는 6개 앱이 이에 해당)

6개로 운영하는 이유 (쓰로틀링 분산)​

  • Microsoft Graph(M365 API)에는 쓰로틀링(Throttling)이 있습니다. 서비스 가용성·안정성을 위해 일정 시간 내 호출량을 제한하며, 한도 초과 시 해당 앱의 추가 요청을 일정 시간 제한하고 HTTP 429(Too Many Requests)를 반환하며 응답 헤더에 권장 대기 시간을 담아 보냅니다.
  • 이 한도의 상당수가 앱(애플리케이션) 단위로 적용됩니다.
  • 따라서 호출을 단일 앱에 집중시키지 않고 여러 앱으로 분산하면, 각 앱이 별도의 한도를 갖게 되어 단일 앱이 한도에 걸릴 가능성을 낮출 수 있습니다.
  • 현재 SHIELDRM 앱을 6개(Main + Sub1~5) 운영하는 것은 이러한 쓰로틀링을 완화하기 위한 구성입니다.

참고 문서​